By the Apple Computer OpenDoc Human Interface Team
As published in the October 1995 Apple Directions
This time, we're covering several questions about OpenDoc's behavior when multiple parts are involved, the mechanics of bringing content into and out of an OpenDoc document, and scripts that are tied to an OpenDoc part. There should be something for everyone here.
Q: I'd like to be able to select content within different parts of the document at
the same time. For example, I want to select a word in a text part, an oval in a
drawing part, a clock part, and a complete drawing. Will I be able to do this in
OpenDoc?
A: That depends. The content you're describing could all be part of a continuous multiple selection, if the containing part's content model allows that; or, it could be a discontinuous selection. Discontinuous multiple selections can be made only within a single part, not among multiple parts.
OpenDoc doesn't allow discontinuous selection across part boundaries, because all parts do not provide the same commands, and consequently it would be difficult for the user to predict what will happen to the selection. Because of this, OpenDoc displays only the menus of the active part;
it supports menu switching, rather than menu sharing.
If the user attempts a selection that crosses part boundaries, OpenDoc displays the menus of the parts' container (that is, the next hierarchical level up), which may or may not support the commands the user wants to invoke.
There are several alternatives to the above and we considered many during the design of OpenDoc. Here is one example of an alternative that we felt would not be successful, along with why we felt it was problematic: Allow users to select content from multiple kinds of parts and show the intersection of the applicable commands in the menus. In order to do this, OpenDoc
would have to determine what kind of parts and what kind of content were selected, and then determine which commands would apply to all of them. This results in a significantly reduced set of commands that could be used on the selected parts. This seriously constrains what the user ca do to those parts, and thus is far from optimal.
Another problem that could occur is that, while several different parts might have certain commands in common, a single command might produce a different effect when applied to different kinds of content. For example, if the user selects a music staff and a graphics object and invokes the command Scale, that command could very well produce a different effect on each type of content: The music staff might play a musical scale, and the graphics object might change its relative size. Imagine the kinds of unexpected behavior this problem might create.
For these reasons, we decided against this approach and decided to limit the user's selection to a single content/part kind. We think this, along with the menu switching capability, will clarify to the user what commands are available.
Q: I'd like to have a universal tool bar that contains standard tools that apply to
content for all different kinds of parts. For example, I'd like to use the same
paint bucket tool to change colors in my paint part and my word processor part.
Will OpenDoc let me do this?
A: This is an interesting idea, but OpenDoc does not provide a facility like this. There are different ways of interpreting what you've asked. As described above, menus switch as a part becomes active. Likewise, tool palettes, rulers, and so on also switch, so it isn't possible to use the same tool in different parts. However, if you are simply suggesting that it would be nice to have a standard set of tool icons across different part editors--that's certainly possible.
A related issue is reusing the same tool palette but having the tools within that palette change according to the part that is active. For example, a part editor developer may decide to reuse a "standard" tool, such as a text tool or a paint bucket tool. Reuse assists users in predicting the behavior of the tool and gives them the perception of universality that doesn't cost developers
anything to provide. (In fact, this decreases your development time.) The OpenDoc human interface guidelines encourage you to reuse functionality from other editors so that you don't have to create it all yourself. (For details, see Q&A #4. )
We aren't delivering any code to support multiple parts sharing the same palette in release 1.0, but because many people have expressed interest in this, we are considering it for the future.
Q: My text part does not support embedded parts. If other text is pasted or
dropped into it, the content is merged. But what should I do when a user copies
some text that contains embedded parts, and then pastes this into my text part?
Should my editor paste in the text, ignoring the other "nontext" parts, or should
it refuse to paste anything?
A: We encourage you to support embedding to maximize data transfer and to minimize user confusion. However, if you are unable to support embedding, you must be able to handle pasting data in special ways and inform users of the implications.
Consider the following example: A user copies some text and graphics from a text part and pastes it into an e-mail part. Depending on how the e-mail editor handles the information it gets from the Clipboard, typically some of the content will be pasted and some of it will be lost. When the text part's Copy command is invoked, it copies the selected content to the Clipboard in several
different formats. One of the formats is "text without graphics," which the e-mail part can accept. Then, when the user pastes the content into the e-mail part, the "text without graphics" data is pasted in and the other nontext data is ignored.
Similarly, when your part editor copies content onto the Clipboard, one of the formats it should supply is "content minus any embedded parts." Thus, parts that don't support certain types of data will be able to receive as much of the copied data as possible during a paste operation. The objective is to allow the user to transfer as much data as possible during a copy-paste operation.
If you are unable to support embedding, you may want to display the embedded content as being of type NoPart, which causes a gray box to appear until the relevant editor is available or the user translates the part. The gray box alerts users to the fact that your editor could not display some of the pasted content. An alternative is to notify the user that only some of the content can be pasted. In this case, we suggest using the alert shown below.
Q: What should happen when a user copies non-OpenDoc content into an
OpenDoc document and vice versa?
A: A key goal of the OpenDoc user experience is something we call "round-trip integrity." By this we mean that content being moved from one place to another should not be altered unnecessarily. For example, dragging any content into an OpenDoc document should not alter the content after it is dropped. The intent is that the user should be able to drag it back out to the Finder and the content that is dropped will be identical to the original.
In other words, if the user copies a drawing document from the Finder into an OpenDoc document, the drawing content inside the OpenDoc document should contain all the content and properties from the original drawing document. For example, all of the contents (in all of the stored representations) should be preserved, as well as the name of that drawing, the kind of the content, the last editor used to edit that drawing, and so on.
There is one exception to this rule, which occurs in the case of merged content. If a drawing is copied into a drawing part, the contents of the drawing are merged into the destination part instead of being embedded in it. In this case, the destination part uses only one of the content representations; any others are discarded. In addition, the properties of the original drawing document are not preserved, because the drawing is now part of its new home and will inherit the appropriate properties of the containing document. It has a new identity!
Another important aspect of the data interchange issue has to do with a part's kind, which is one format (or "representation") of a part's content. A standard kind is a data format widely used among traditional applications--for example, "styled text" is understood by many word processors. It is important that your editor not arbitrarily change a standard kind to an OpenDoc-specific kind.
For example, let's assume that SurfWriter 1.0 is a traditional application and SurfWriter 2.0 is an OpenDoc part that allows embedding. When the user drags SurfWriter 1.0 content into an OpenDoc document, your SurfWriter 2.0 part editor should not automatically change the content's kind to SurfWriter 2.0 just because it's now residing in an OpenDoc part. Leave the content's kind alone! That way, the user can later extract the content (whose kind is SurfWriter 1.0) and give it to someone who doesn't have OpenDoc.
The representation and kind of the part should only be changed when the user has made some change that absolutely cannot be handled by the old representation. For example, when the user embeds another part into our example SurfWriter 1.0 part, its representation and kind must be changed to one that supports embedding--because the SurfWriter 1.0 representation does not support embedding. After this, the kind cannot be changed back, because to do so would require removing the embedded part.
One final note on kinds: The user has control over the content's kind. In the Part Info dialog box, the part's kind is shown in a pop-up menu. All kinds that the editor supports--for example, SurfWriter 1.0 and 2.0--will be in that list, as well as a mechanism for translating to other kinds. The user may change to any supported kind. Of course, the kinds available in the pop-up menu may change over time. For example, if you look back at our previous example, once the part's kind has been changed from SurfWriter 1.0 to 2.0, the SurfWriter 1.0 kind would no longer be found in the pop-up menu.
Q: My part has several different tool palettes and rulers. Where should I initially
place these?
A: Our human interface guidelines suggest pinning to the upper left. Therefore, place your main palette in the upper left of the screen. When the user's system has multiple screens, place the palette on the same screen as the document window it supports. The most important considerations for placement of tools are proximity to content, flexibility of placement, and reachability. In other words, users should be able to easily associate the tool with the content it modifies. The user should also be able to change the location of the palette (and the system should
remember the new location). Finally, the user should be able to hide and show the palette, dismiss it (using a close box), and recover it (using a menu command).
If the document contains several parts that use the same part editor, the palettes should be positioned in the same spot on the desktop, regardless of which part is active. The palette should not be affixed directly to a part--this is an inefficient use of screen real estate and would cause unnecessary repainting of the document when another part becomes active. Positioning your tool palette inside your part not only artificially increases the size of your part, but can obscure content within your part or cause content in the container to reflow. This would violate the WYSIWYG
principle.
When your part is the root part and your editor supports a ruler, place that ruler at the top of the window. When the part is inactive it should still display the ruler, since the user may find it useful when looking at the placement or content of embedded parts.
If a ruler is necessary for a part that is embedded, you can use overlaid frames if the container supports them (in this case, an overlaid frame would be a ruler that appears just above the embedded part), but in certain situations this solution doesn't work well. In these situations, we recommend that you create a floating window to contain the ruler, and place the window so that it is adjacent to the relevant side of the part (the ruler could be horizontal, vertical, or both, depending on the content model). Further, users should be able to dismiss rulers.
We appreciate any comments you have on this topic; you can send them to the address OpenDoc-Interest@CILabs.org.
Q: How do I attach scripts to OpenDoc parts?
A: Scripting allows customization of the interface. We expect that most users will experience scripting indirectly, by using documents created from commercially available stationery that contains embedded scripts. For example, in filling out an electronic medical form, a user might be unaware that an embedded script is invisibly validating data as it is entered. Nonetheless, we want you to know how scripting works in OpenDoc and what kinds of user interfaces you should support in order to allow scripts to be added to parts.
Conceptually, scripts may be attached either to the part as a whole or to some intrinsic content within the part (for example, text fields, menu commands, command buttons, radio buttons, pop-up menus, or other controls and graphics objects). Any part may have a script property associated with it, and the script may be attached in many ways, which will be explained later.
If a part editor supports attaching scripts to its intrinsic content, the intrinsic content--a text field, for example--has no script property in which to store the script because it is only one element of the part itself (which can have its own script property). Still, the user interface for the intrinsic content's script should be similar to that used for attaching scripts to embedded parts, and there should be no difference between editing the script of a part and editing the script of a part's
intrinsic content.
There are several ways that a user can attach scripts to parts. One way is the required user interface method and the others are alternative methods. The required method involves the Part Info dialog box. A user can create and edit a part's script by selecting the part, choosing the Part Info command from the Edit menu, and clicking the Settings button. This opens the script for this part and allows the user to edit it. Please be aware that, as the part developer, you are responsible
for adding the Settings button to your part's Part Info dialog box.
One optional method for attaching a script to a part is through menu commands. When a part is activated, its menus are displayed and, if your part supports scripting, you can add commands to your part's menus that provide direct access to its script editor. You may also provide keyboard shortcuts, such as the Command-Option-click shortcut that HyperCard uses, to provide direct access to your part's script editor. Another optional method for adding a script to a part is through the drag-and-drop feature. For example, if the user drags and drops an OSA (Open Scripting
Architecture) script file onto a button part, the button part editor should copy the contents of the script into the button's script property.
